home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / 92nov / area.operations.92nov.txt < prev    next >
Text File  |  1993-02-17  |  10KB  |  244 lines
  1.  
  2. Operational Requirements Area
  3.  
  4. Director(s):
  5.  
  6.  
  7.    o Phill Gross:  pgross@nis.ans.net
  8.    o Bernhard Stockman:  boss@ebone.net
  9.  
  10.  
  11. Area Summary reported by Bernhard Stockman/SUNET
  12.  
  13. BGP Deployment and Application Working Group (BGPDEPL)
  14.  
  15. The BGPDEPL Working Group met for one session during this IETF chaired
  16. by Matt Mathis.
  17.  
  18. Of the approximately 5000 networks which are currently reachable, almost
  19. 3000 are being announced with EGP2.  This situation is pretty bleak.
  20. There is only a short time available to test and deploy BGP-4, and
  21. operators who have not yet deployed BGP-3, will face additional
  22. difficulties phasing out EGP-2.  It is desirable for all network
  23. operators to have BGP experience as soon as possible.
  24.  
  25. Proposed deployment schedule for BGP-4/CIDR:
  26.  
  27.  
  28. 1/93-3/93     BGP-4 interoperability testing with the ANS testing
  29.               facility (See below - all vendors are invited to
  30.               participate).
  31. 3/93          BGP-4 capable code deployed in the production NSFnet
  32.               backbone.  Begin testing by propagating some test CIDR
  33.               networks through the backbone.
  34. 6/93          Start aggregating *production* networks in the backbone.
  35. 12/93         Completely phase out all EGP-2 on NSFnet DMZs.
  36.  
  37.  
  38. There was some discussion about how this interacts with the new network
  39. assignment rules and schedule specified in RFC1366 and RFC1367.  The
  40. first aggregation of production networks (scheduled for June 1993) will
  41. be a flag day for any site requiring full routing tables and not running
  42. BGP-4.
  43.  
  44. Jordan Becker (ANS) estimated that full route aggregation will reduce
  45. the current routing tables by about 30%, because the old address
  46. assignment policies tended to allocate addresses in blocks anyhow.
  47.  
  48. cisco's next scheduled code freeze is February 1993, so even if bug-free
  49. BGP-4 code exists today, the earliest it will appear in General
  50. Availability products is October 1993.  All customers who need BGP-4
  51. before then must run pre-GA code.
  52.  
  53.                                    1
  54.  
  55.  
  56.  
  57.  
  58.  
  59. Benchmarking Methodology Working Group (BMWG)
  60.  
  61. The BMWG Group met during one session Chaired by Scott Bradner.  The
  62. Group discussed various test frame formats to be used in conjunction
  63. with earlier described network device testing methods as described in
  64. RFC 1242.
  65.  
  66. Some router vendors have announced inadequate performance metrics with
  67. no consistent way defined for measuring of router performance.
  68.  
  69. In some network devices, packet forwarding has priority above other
  70. functions which could result in loss of learning tree for bridges and
  71. loss of routing information for routers when the device is loaded.
  72.  
  73. The Working Group discussed Performance impacts of filter lists.
  74. Various sizes of filter lists have been tested.  Some vendors use
  75. hash-search where there is no significant difference in performance
  76. between various sizes of filter lists.  When linear search is used the
  77. amount of list entries is proportional to the performance impact.
  78.  
  79. Finally the Working Group discussed the performance impact of network
  80. management.  It was noted that some network products do not update the
  81. SNMP MIB database as often as the hardware updates its counters.  There
  82. may thus be a discrepancy between what actually is going on and how this
  83. is reflected in the MIB database.
  84.  
  85. Network Status Report (NETSTAT) and Network Joint Management Working
  86. Group (NJM)
  87.  
  88.  
  89.    o Mark Knopper, Merit, Jordan Becker, ANS - NSFnet:  Transition T1 ->
  90.      T3 ongoing.  In October, 18.9 billion packets carried on T3 while
  91.      T1 steadily decreasing Number of nets is 7354 whereof 2566 is
  92.      foreign networks.  OSI traffic 600000 - 1000000 packets per month
  93.      during March to October 1992, August and September close to zero
  94.      though.  T3 not yet ready to forward native CLNP which will be
  95.      carried encapsulated in IP. Of NSFnet/ANSnet configured networks
  96.      nearly six thousands are actively announced.  Around 90 percent of
  97.      the networks are using T3 as primary.
  98.  
  99.       -  The T3 backbone implementation.  Dummy AS support for load
  100.          splitting.  Up to 5 high speed interfaces per router with 20
  101.          kpps in and out per interface and total of 50 kpps per router.
  102.          Max performance is 22 Mbps in each direction at 270 byte
  103.          packetsize.  One way router hop delay = 0.165 msec which gives
  104.          cross country router delay (8 hops) of 1.35 msec and a total
  105.          cross country delay of 35 msec.  A ping version using NTP for
  106.          microsecond resolution is used.  The dismantling of T1 backbone
  107.          lines starts 12 Feb.
  108.       -  T3 Network Status.  Announced corrections in peer behavior.
  109.          Engineering changes in internal routing to minimize delay
  110.          through T3 net.  Map with delay numbers will be available
  111.  
  112.                                    2
  113.  
  114.  
  115.  
  116.  
  117.  
  118.          on-line.  Deployment underway of encapsulated CLNP across T3,
  119.          to enable decommissioning of T1 very soon.  Announced
  120.          deployment of BGP4 in spring.  Invited vendors & operators to
  121.          use ANS testnet.
  122.          Support for CIDR is planned to start January 93.
  123.  
  124.    o DECNET IV support
  125.  
  126.       -  Multiproto routers
  127.       -  Elimination of upgrade of tail circuits
  128.       -  Multinet DECNET in TCP encap support
  129.       -  Throughput on T1 over 200 Kbps
  130.       -  Gradual transition (if any) to DECNET V
  131.       -  Native DECNET not considered due to sever loss of performance
  132.          depending on DECNET resend algorithm.
  133.  
  134.  
  135.    o Milo Medin - NASA Science Internet:  Awaiting US Department of
  136.      Commerce clearance for connection to Russia.  NASA portion of
  137.      DoE/NASA ATM will ' initially include Langley, Lewis, Goddard,
  138.      Ames, JPL.
  139.  
  140.    o Bernhard Stockman - EBONE: Deploying security access scheme in
  141.      EBONE routers - combination of kerberos and TACACS. Plan for link
  142.      from Stockholm to Bonn.
  143.  
  144.    o Bob Collet - Sprint:  Sprint operates three logically distinct IP
  145.      networks - domestic US, Atlantic-Europe-Mideast, and Pacific.
  146.      Exclusively Cisco routers showed new maps with new perspectives.
  147.  
  148.    o Rich Fisher - GSFC: Satellite data collection & redistribution to
  149.      distant research and processing centers.
  150.  
  151.    o Tony Hain - ESnet:  ATM project sites Livermore, LBL, LANL, Fermi,
  152.      Oak Ridge, SuperCollider All local loops will be fiber.
  153.  
  154.    o Mark Knopper - ERNET: Networking in India Funded by Indian
  155.      governmental and UN plan to ``upgrade'' to vsat connections
  156.      domestically to overcome shortcomings in domestic infrastructure.
  157.  
  158.  
  159. Operational Requirement Area Directorate (ORAD)
  160.  
  161. The meeting discussed requirements of ORAD and its members.  ORAD is
  162. expected to guide other working groups and review documents with special
  163. attention to operational needs.  Current Operations Area working group
  164. Chairs could be part of ORAD, but this is not implicitly required.  To
  165. make ORAD have broad coverage it will be necessary to invite operators
  166. who have not traditionally participated in IETF meetings.
  167.  
  168. The meeting concluded that ORAD should not start off too big but
  169.  
  170.                                    3
  171.  
  172.  
  173.  
  174.  
  175.  
  176. initially concentrate on document review and presentation of issues to
  177. working groups.
  178.  
  179. Finally, the Group discussed various operational aspects of the ongoing
  180. audio and video multicast from IETFs.  MBONE routers shall be positioned
  181. as high as possible in the topology.  An ORAD operations recommendation
  182. was discussed.  A variety of actions to improve the current MBONE
  183. implementation were identified.  Tests shall happen before IETFs, which
  184. include announcements of tunneling and requests to be made further in
  185. advance of conferences, and a strict cut-off date after which there will
  186. be no more tunnels.
  187.  
  188. Operational Statistics Working Group (OPSTAT)
  189.  
  190. Before this meeting the Internet-Draft on a model for operational
  191. statistics had been submitted as an Informational RFC. This time the
  192. Working Group restarted the work on the client/server based protocol for
  193. retrieval of statistical data.  Most of the simple commands where kept
  194. as is while the more complex part were significantly modified.  Some
  195. discussion centered around where the selection processing should be
  196. done.  For example, should the conditionals be processed on the server
  197. or client?  Great economies could be realized by processing the
  198. conditional on the server versus downloading all data to the client and
  199. processing it there.  Some discussion revolved around the SQL-ness of
  200. the select command.  Consensus not to make it more complex than it
  201. already is.  As the storage format in the above mentioned RFC has
  202. changed since the client/server specification was initially drafted it
  203. was necessary to change some part of the client/server command language
  204. to reflect this.  Finally the Goals and Milestones section of the OPSTAT
  205. Charter was reviewed and updated.
  206.  
  207. User Connectivity Problems Working Group (UCP)
  208.  
  209. The Group had previously defined a data structure that would enable
  210. Trouble Ticket hand-offs between NOCs.  Paul Zawada had written an
  211. ASN.1-like description of the fields in this data structure.
  212.  
  213. Kaj Tesink drafted a document describing how some hand-off fields could
  214. be represented in electronic mail messages.  The Group discussed this
  215. and agreed that the document needs to be revised to reflect more of the
  216. previously-defined hand-off fields.  The goal is to allow trouble
  217. tickets to be mailed between NOCs both with and without internal trouble
  218. ticket systems.  The format should be simple enough to enable humans to
  219. enter the data and yet regular enough to permit parsing.  Paul and Kaj
  220. will work on this and get it out as an Internet-Draft.  At that time,
  221. several groups agreed to experiment with the exchange format and to
  222. create a template to facilitate manual participation.
  223.  
  224. The UCP Internet-Draft on a Trouble Ticket Tracking System, originally
  225. written by Matt Mathis, had been discussed and revised heavily by the
  226. Group and it has now expired.  Dan Long has volunteered to draft a new
  227. version which reflects the current consensus of the Group.  This will
  228.  
  229.  
  230.                                    4
  231.  
  232.  
  233.  
  234.  
  235.  
  236. also be published as an Internet-Draft.
  237.  
  238. The Group also discussed the current status of various publicly
  239. available internal Trouble Ticket systems.
  240.  
  241.  
  242.  
  243.                                    5
  244.